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REMARKS 

1. Status of the Application 

Claims 1-28 are pending in this application and claims 29-55 have been previously withdrawn. In 
the January 25, 2008 office action, the Examiner: 

A. Rejected claims 1-3, 5-17 and 19-28 under 35 U.S.C. § 103(a) as being 
unpatentable over U. S, Patent Number 7,017,146 to Dellarocas et al. (hereinafter "Dellarocas") 
in view of U. S. Patent Number 6,141,595 to Gloudeman et al. (hereinafter "Gloudeman"); 

B. Rejected claims 4 and 18 under 35 U.S.C. §103(a) as being unpatentable over 
Dellaorocas in view of Gloudeman, and further in view of U. S. Pub 2003/0229652 to Bakalash 
et al (hereinafter "Bakalash"). 

n. Response to Office Action 

In this response, Applicant has amended claims 1, 5-7, 9-13, and 15 and responds with 
arguments as presented below. 

The Section 103 Ground of Rejection Should Be Withdrawn Because Gloudeman Does 
Not Teach Or Otherwise Disclose A Data Provider Interface As Required Bv The 
Pending Claims 

Claim 1 requires: 

a data provider interface configured to convert database 
instructions conforming to a common database access method to 
database queries conforming to a database application 
programming interface (API) and to convert database responses to 
the common database access method. 

The Examiner asserts that Gloudeman at col. 5, lines 1-48 "teaches a data provider interface for 
converting between a common database access method and a database application programming 
interface (API)". Ojfice Action of January 25, 2008, p. 4, lines 4-6. Applicant respectfully 
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disagrees. While Applicant maintains that Gloudeman shows no component that converts between a 
common database access method and a database API, Applicant has amended claim 1 to more 
particularly set forth the configuration of the data provider to clarify the differences between the 
data provider of claim 1 and the cited Gloudeman reference. Specifically, the amended claim 1 
requires the conversion of database instructions from a common database access method and the 
conversion of database responses to the common database access method. Because Gloudeman fails 
to teach these limitations, claim 1 is patentable. 

As recited in claim 1, the data provider interface converts database instructions conforming to a 
common database access method to database queries conforming to a database API. As depicted in 
FIG. 1 A, this element is interposed between application programs 30a . . . 30n and the database 18. 
The data provider services 20 that comprise the data provider are also shown in FIG. 2A as 
providing bi-directional communication between the databases in database 18 and the applications 
in the solutions 14. In this intermediary role, the data provider interface converts instructions that 
conform to a common database access method to database queries that conform to an API for a 
database in database 18. This conversion enables all of the applications to be written with conmion 
database instructions so the building system designer can focus on the design of building system 
solutions and not on the intricacies of an interface to a database from which data is to be drawn. 
Likewise, the responses received by the data provider interface from a database API are converted 
to database responses that conform to the common database access method so the designer can use 
the responsive data without having to be knowledgeable about the various forms in which a 
database API returns data. 

The Gloudeman reference discloses no structure for performing these tasks. In the paragraph 
beginning at col. 4, line 58 and ending at col. 5, line 9, Gloudeman discloses two interfaces 
"through which other systems may be coupled to the building automation system." Gloudeman, col. 
4, lines 58-61. The first interface 54 requires no conversions because the systems external to the 
building automation system already communicate in data protocols and formats that are compatible 
with the APIs of the building automation system. The second interface 56 includes the necessary 
protocol converters and data migration tools that enable third party systems, which do not 
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communicate in a manner that conforais to the first interface, to communicate with the building 
automation system. Both of these interfaces, however, couple the user interface applications of the 
information layer 50 (Gloudeman, col. 4, lines 25-44) to the building system interface 74, and not to 
the system database APIs 76 (FIG. 2). 

The structure disclosed in Gloudeman is significantly different than the structure set forth in claim 1 
for a number of reasons. For one, the user interface applications of the information layer are not 
disclosed as communicating with databases through instructions that conform to a common 
database access method. In fact, Gloudeman teaches away from that limitation as two interfaces 
must be provided. The provision of two interfaces demonstrates Jhat no common database access 
method exists for the applications of the information layer. If a common database access method 
were used, only one interface would be needed to receive communications from the information 
layer. Additionally, Gloudeman does not disclose that either interface alone receives 
communications that conform to a common database access method. The standard interface 54 
performs no conversion so the applications of the information layer that communicate through this 
interface provide database instructions that conform to the API of the database from which data is 
being sought. Without conversion functionality, the standard interface 54 cannot be a data provider 
as set out in claim 1. The third party interface also does not receive database instructions that 
conform to a common database access method because communications from each external system 
are converted to not from a common interface. The clear teaching of Gloudeman is that each third 
party system communicates in its protocol and data format and that the third party interface converts 
communications from the information layer to a common building system interface. That is, the 
third party interface of Gloudeman is the opposite of the claimed data provider, which converts 
from a common database access method to the database API coupled to the data provider. 
Consequently, the two interfaces between the information layer and the building system interface do 
not perform the conversions required by claim 1 and they cannot support the Examiner* s assertion 
that Gloudeman teaches the data provider required by claim 1. 

The building system interface also fails to support the Examiner's position that Gloudeman teaches 
a data provider as required by claim 1 because the building system interface of Gloudeman does not 



14 



2003P14526US (1867-0008) 

teach the conversion of any data. Rather, the building interface system is described as a 
communication engine that routes data amongst the various layers of the system and that 
"communicates data from various building systems, including environmental, lighting, fire, security, 
power management, inventory, and maintenance." (Gloudeman, col. 5, lines 41-47). Consequently, 
routing, and not conversion, is the function that Gloudeman teaches for the building system 
interface. 

The Examiner also cannot rely upon the system database APIs 76 as being evidence of a data 
provider. Although the system database APIs access and populate the data stores, (Gloudeman, col. 
5, lines 41-48), they do not convert database instructions conforming to a common database access 
method to a database API. As shown in FIG. 2 of Gloudeman, the system database APIs are only 
coupled to the real-time applications and the optimization applications. The use of the plural form 
(APIs) indicates that each data store presents its own API to the real-time applications and the 
optimization applications. These applications are shown in FIG. 2 as being coupled to the various 
APIs without a common converter or data provider. Thus, the application programs must be capable 
of communicating with each system database API with queries that conform to the API for the 
database and to receive responses from the data stores that conform to the database API, not a 
conmion database access method. 

Finally, the control layer 52 is described as "supporting various control devices ... as well as 
applications defined for interaction with such devices." Gloudeman, col. 4, lines 37-41. This 
description indicates that the layer 52 does not communicate database instructions or database 
responses. Instead, the layer communicates device instructions and device data between control 
applications and control devices. Thus, the control layer cannot operate as a data provider as 
required by claim 1. 

For the reasons set forth above, Gloudeman cannot support the Examiner* s position that the prior art 
discloses a data provider as required by claim 1. Therefore, claim 1 is patentable over all references, 
either alone or in combination. 
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The burden of proof is on the Examiner, who must show that a cited reference teaches a limitation 
of a claim. Gloudeman does not show a data provider that converts instructions that conform to a 
common database access method to database queries that conform to a database API and that also 
converts database responses from a form conforming to a database API to the common database 
access method. Instead, the plain implication of the plural form of APIs indicates that any 
application program or interface communicating with the system database APIs must generate 
database queries that conform to the API for a particular database and be capable of receiving and 
processing responses that also conform to the API for that database. The two interfaces cited by the 
Examiner are not disclosed as being database interfaces and they are not described as performing 
the functions set forth in claim L The Examiner is only able to install such functionality in these 
two interfaces by importing Applicant's teachings into the Gloudeman reference. Such usage of 
Applicant's specification is impermissible hindsight and does not appropriately support the section 
103 ground of rejection relied upon by the Examiner for the stated rejection of claim 1. For at least 
these reasons, claim 1 is allowable over all references of record, either alone or in combination. 

The Section 103 Ground of Rejection Should Be Withdrawn Because Modification of 
Dellacoras To Include A Data Provider Is Unreasonable 

The Examiner's proposed combination of Dellacoras and Gloudeman also fails because the 
Examiner has not put forth a credible reason for modifying Dellacoras to include a data provider as 
required by claim 1. As noted above, the proposed combination cannot modify Dellacoras with a 
data provider because Gloudeman does not teach a data provider that is configured to convert 
database instructions and database responses as required by claim 1. Additionally, Dellacoras fails 
to recognize a need to convert between a database common interface method and a database API. 
As noted by the Examiner, a database resource from the database 210 is made available to user 
activities 212, 214 through a flow dependency 220. Dellacoras, col. 17, lines 43-51. Dellacoras 
does not discuss any database API or any need for the flow dependency to convert communications 
between the user activities and the database 210. Therefore, one of ordinary skill in the art would 
not modify Dellacoras to include a data provider that performs the conversions required in claim 1. 
The opening discussion of databases in Dellacoras at col. 6, line 58 to col. 7, line 15, does not 
disclose any conversion between a common database access method and the API 36. Likewise, the 
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database access through prerequisite dependency 98, which is discussed at col. 10, lines 34-36, is 
also void of any discussion of a need to convert between a common database access method and a 
database API. Only a person attempting to arrive at Applicant's claimed invention would consider 
modifying Dellacoras to add a converting interface to the flow dependency for database 
communications between the database of Dellacoras and the user activities of the applications 
disclosed therein. Such efforts, however, do not properly support a section 103 ground of rejection 
and thus, claim 1 is allowable over all references of record. 

The Remaining Claims 
Claims 2-14 

Claims 2-14 depend from claim 1 and, consequently, include the limitations discussed above that 
are not disclosed in either Dellacoras or Gloudeman. Thus, these two references also do not fail a 
proper foundation for the rejection of claim 4. Therefore, each of these claims is also patentable 
over all references of record, either alone or in combination. 

Claim 15 

Claim 15 requires the conversion of database instructions conforming to a common database access 
method and the conversion of database responses from a database API to a common database access 
method. Therefore, for reasons similar to those presented above, claim 15 is patentable over all 
references of record, either alone or in combination. Additionally, claim 15 specifies that the 
database instructions be in computer statements that implement control logic of application 
definition data. The database discussions in Dellacoras, which were identified above, do not 
disclose database instructions in reference to the user activities and, especially, do not disclose 
database instructions in computer statements that implement control logic of application definition 
data. Gloudeman also fails to disclose such database instructions as the generation of the control 
applications used in Gloudeman is not discussed. Consequently, neither Dellacoras nor Gloudeman 
disclose database instructions in computer statements that implement control logic of application 
definition data or the conversion of such instructions to database queries that conform to a database 
API. For at least these reasons, claim 15 is patentable over all references of record, either alone or in 
combination. 
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Claims 16-28 

Claims 16-28 depend from claim 15 and, consequently, include the limitations discussed above that 
are not disclosed in either Dellacoras or Gloudeman. Therefore, each of these claims is also 
patentable over all references of record, either alone or in combination. 

m. Conclusion 

For all of the foregoing reasons, Applicant respectfully submits a patentable contribution to the 
art has been made. Favorable reconsideration and allowance of this application is therefore 
respectfully requested. 

In the event Applicant has inadvertently overlooked the need for an extension of time or payment 
of an additional fee, Applicant conditionally petitions therefore, and authorizes any fee 
deficiency to be charged to deposit account 13-0014. 
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